feat: display provider usage limits in settings by Aditya190803 · Pull Request #1732 · pingdotgg/t3code

Aditya190803 · 2026-04-04T10:45:44Z

Fixes #228.

What Changed

Added provider usage limits to the settings flow end to end for all 4 providers (Codex, Claude, Cursor, OpenCode):

the shared contract now includes the usage-limits schema
the server persists and exposes provider usage limits
the web app renders the limits in Settings

Note: For OpenCode, only the official OpenCode-managed providers (OpenCode Go, OpenCode Zen) are shown.

Why

Users need a visible place to confirm provider usage limits without digging through logs or backend state. This keeps the value available across sessions and makes the current limits easy to inspect from the UI.

UI Changes

The Settings panel now shows provider usage limits in the provider section.

Checklist

This PR is small and focused
I explained what changed and why
I included before/after screenshots for any UI changes
I included a video for animation/interaction changes

Note

Medium Risk
Adds a new cross-cutting usageLimits field to provider snapshots and wires in new probing/state logic (including PTY-based Claude probing and runtime-event ingestion), which could affect provider status checks and event flows but is largely additive.

Overview
Adds end-to-end support for provider usage limits (session/weekly quota windows) by extending the contracts schema with ServerProviderUsageLimits and propagating usageLimits through server provider snapshots, cache hydration, and serialization.

Implements new server-side usage collection: Codex now optionally fetches account rate-limit snapshots; Claude can probe /status and fall back to /usage via a PTY helper (claudeUsageProbe) and also tags runtime events with providerInstanceId; Cursor maps ACP usage_update notifications into thread.token-usage.updated and a new ProviderUsageStateLive layer tracks latest usage per provider+instance from runtime events.

Updates the web Settings UI to render color-coded usage bars (and “unavailable” reasons) on provider cards, plus minor work-log filtering to hide quota telemetry activities; includes extensive new/updated tests for parsing, state tracking, and UI rendering.

^{Reviewed by Cursor Bugbot for commit fe88f5b. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Display provider usage limits (session/weekly windows) in provider settings cards

Adds ServerProviderUsageLimits to the contracts schema and propagates it through provider probes for Codex, Cursor, Claude, and OpenCode providers.
Introduces ProviderUsageStateLive, a new server-side service that maintains per-provider usage state from runtime events (Cursor token usage, Claude rate limit telemetry) and exposes get/set/clear effects.
Adds claudeUsageProbe.ts, which spawns a PTY to parse Claude's /status and /usage output into normalized session/weekly usage windows.
Renders usage bars in ProviderInstanceCard with color-coded fill (warning ≥70%, destructive ≥90%) and reset timestamps; shows an unavailable message when data cannot be obtained.
Filters account quota telemetry activities (account.rate-limits.updated, account quota updated) from the session work log via isHiddenWorkLogTelemetryActivity.
Behavioral Change: provider status checks for Claude and Cursor now accept optional ProviderUsageState and PTY adapter dependencies wired in from the server layer.

^{Macroscope summarized fe88f5b.}

coderabbitai · 2026-04-04T10:45:52Z

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 8cfd6712-1535-4e1a-b539-31b4ea39f747

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Aditya190803 · 2026-04-04T10:50:03Z

For now, I’ve added two images to illustrate the UI:

1. Free tier view

This screenshot reflects my current setup. I don’t have subscriptions to Codex or Claude Code, I’m using Copilot Pro (available to me as a student). It shows how the weekly usage limit appears in the interface.

2. Pro tier (mocked example)

This second screenshot uses dummy data to demonstrate how the UI could look for users on a Pro plan (Codex or Claude Code). It includes both session-based limits and weekly limits for clarity.

chatgpt-codex-connector

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 80515efa38

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

Open a pull request for review
Mark a draft as ready
Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

chatgpt-codex-connector · 2026-04-04T10:52:45Z

+            state?.usageLimits
+              ? usageLimitsRepository
+                  .upsert({
+                    provider: PROVIDER,
+                    usageLimits: state.usageLimits,


Stop re-persisting stale cached Codex usage limits

This Effect.tap writes the accountProbeCache value back into provider_usage_limits on every Codex status check. Because the probe cache is valid for 5 minutes, a newer usage-limit update persisted from runtime events (via ProviderService's account.rate-limits.updated handling) can be overwritten by this older cached snapshot, causing limits to regress in storage and UI until cache expiry. Please avoid upserting cached probe data unconditionally (or at least reject older timestamps).

Useful? React with 👍 / 👎.

chatgpt-codex-connector · 2026-04-04T10:52:45Z

+  const usageLimits = isResolvedCodexAccountState(account)
+    ? (account.usageLimits ?? cachedUsageLimits)
+    : cachedUsageLimits;


Prefer persisted usage limits over account-probe cache

When both values exist, this branch prioritizes account.usageLimits from the 5-minute accountProbeCache and ignores cachedUsageLimits loaded from persistence. That means even after a fresh runtime usage-limit event is stored, provider refreshes keep serving stale probe data instead of the latest persisted snapshot. Reversing this precedence prevents stale limits from being shown after updates.

Useful? React with 👍 / 👎.

macroscopeapp · 2026-04-04T11:06:31Z

Approvability

Verdict: Needs human review

This PR introduces a new feature for displaying provider usage limits with significant new logic across multiple provider drivers and state management. Multiple unresolved P1 review comments identify potential bugs in usage limit caching and persistence logic that require attention.

^{You can customize Macroscope's approvability policy. Learn more.}

Aditya190803 · 2026-04-06T04:50:58Z

Hey @juliusmarminge, could you take a look at this PR when you get a moment? Thanks!

Marve10s · 2026-04-06T21:22:58Z

Randomly found this PR because wanted to add usage to T3. I think this is great as a user but also I think the UI should match the Codex App usage,it's minimal and clean, would be better than AI tabs

You would need to redo the settings button though,something Julius needs to approve. I genuinely think settings button should match Codex App, would love to open PR for that.

Marve10s · 2026-04-06T21:35:36Z

A few concerns after checking the code:

Codex can prefer stale persisted usage over freshly probed usage in the same refresh path.
checkCodexProviderStatus() reads cachedUsageLimits first, then later resolves account state, but ultimately uses cachedUsageLimits ?? accountUsageLimits. That means a refresh can still emit an older persisted value even when the same refresh just fetched newer limits from the provider probe. If the goal is to show the freshest available snapshot, I think the precedence likely needs to be reversed, or persisted data should only be used when no fresh usage was fetched.
The persisted cache looks too coarse-grained for account/config changes.
The new table is keyed only by provider_name, and the repo API is also getByProvider only. That seems risky if the user changes auth state, swaps Codex homePath, changes binary path, or otherwise changes the effective account behind a provider. In those cases we can still surface previously persisted usage for the provider even though it may belong to a different account/config. Is that safe, or should this cache be scoped more tightly (for example by provider + account/config fingerprint) or suppressed when provider health/auth no longer matches the cached source?
A usage-limit update currently looks like it can trigger full provider refresh work.
ProviderService persists account.rate-limits.updated, then ProviderRegistry listens to repository changes and calls refresh(change.provider). That refresh path eventually reruns the provider's checkProvider flow rather than just updating already-known snapshot state. For a quota-bar style UI update, this feels heavier than necessary and could add extra CLI churn to a hot path. Would it be simpler to keep usage attached to the provider snapshot/update flow directly instead of going through persistence -> repository stream -> provider refresh?

I can test further and commit to this PR if you're okay with it, @Aditya190803. Genuinely want to see this merged - it would be super useful

juliusmarminge · 2026-04-06T21:50:33Z

this is on my list to review still! Just dealing with some larger prep work so haven't had time yet.

As for the "it must be more visible and sjhould be 1:1 like codex app":

How often do you guys check your limits to warrant it being one click ??? I check it at most a few times a week, so hiding it in settings next to the provider status is fine!

Marve10s · 2026-04-06T21:57:51Z

this is on my list to review still! Just dealing with some larger prep work so haven't had time yet.

As for the "it must be more visible and sjhould be 1:1 like codex app":

How often do you guys check your limits to warrant it being one click ??? I check it at most a few times a week, so hiding it in settings next to the provider status is fine!

I've been checking usage a lot in Codex - a couple of times daily since I was on the $20 plan with 2x limits till April, so I was curious how it was going. My take is that the current settings are genuinely fine, but I think it'll get crowded soon. With usage, OpenCode and Cursor support, and I'm sure there are PRs that extend the settings further it's going to contain a lot of content before long.
Codex shows a small tab with everything you need: usage, general info, and language (something I'd tuck away in settings). I think the Cursor settings approach is a good reference here too.

juliusmarminge · 2026-04-06T22:16:23Z

Yes when the single settings page gets too large we'll split it to subpages. We already did the work adding the sidebar when adding the archive

juliusmarminge · 2026-04-06T22:21:53Z

can't see claude limits:

juliusmarminge

implementation seems way overcomplicated.

why cache the data? the provider check runs once per minute. we can get fresh data on every tick?

how i imaagined this working:

extend the checkProvider probe in ServerProvider to include a new usageLimits property.
on the auth check probes (app server / claude), extract usage data
stream it down to client as part of the normal provider snapshot
render the UI on settings page

given i haven't looked into exactly what's possible to probe and not, why is this PR so much more than that?

Cherry-picked from upstream pingdotgg#1732 Conflicts resolved manually.

…unused checks for pairing_links

…improve server layer integration

…e management

…nd argument parsing

… from server layer

…imports

…ions in usage limits

…te migration entries

Aditya190803 · 2026-05-08T02:55:12Z

@juliusmarminge
Could you review it once more.

Resolved merge conflicts and fixed typecheck errors introduced by origin/main's stricter Effect lint rules (importFromBarrel, globalDate, globalDateInEffect). Migrated barrel imports to subpath imports and replaced Date.now()/new Date() with Effect DateTime/Clock APIs.

…a190803/t3code into feat/provider-usage-limits

…imits # Conflicts: # apps/web/src/components/settings/SettingsPanels.browser.tsx

cursor · 2026-05-15T04:25:06Z

+      method: "session/update",
+      payload: input.rawPayload,
+    },
+  };


Unconditional turnId inclusion inconsistent with sibling functions

Low Severity

makeAcpUsageUpdatedEvent always sets turnId: input.turnId even when the value is undefined. Other functions in the same file with optional turnId (e.g., makeAcpToolCallEvent) use the conditional spread pattern ...(input.turnId ? { turnId: input.turnId } : {}). Including turnId: undefined produces a different runtime object than omitting the key, which can affect serialization and consumers checking key presence with "turnId" in event.

^{Reviewed by Cursor Bugbot for commit a89f9b4. Configure here.}

cursor

Cursor Bugbot has reviewed your changes and found 1 potential issue.

There are 2 total unresolved issues (including 1 from previous review).

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit fe88f5b. Configure here.}

cursor · 2026-05-19T07:43:02Z

    });
  }

+  const claudeEnvironment = yield* makeClaudeEnvironment(claudeSettings, environment);


Claude environment resolved even when result is unused

Low Severity

makeClaudeEnvironment is called unconditionally on line 655, but its result (claudeEnvironment) is only used inside the probeClaudeUsageLimits branch (line 671). When runtimeUsageLimits is already available, or when ptyAdapter is undefined, the environment resolution (which involves path I/O via resolveClaudeHomePath) runs needlessly. Moving the call inside the branch that actually uses it avoids wasted work on every status check that doesn't need to spawn a PTY probe.

Additional Locations (1)

apps/server/src/provider/Layers/ClaudeProvider.ts#L661-L679

^{Reviewed by Cursor Bugbot for commit fe88f5b. Configure here.}

github-actions Bot added vouch:unvouched PR author is not yet trusted in the VOUCHED list. size:XL 500-999 changed lines (additions + deletions). labels Apr 4, 2026

Aditya190803 mentioned this pull request Apr 4, 2026

feat: track provider usage and project weekly quota #1605

Closed

4 tasks

macroscopeapp Bot reviewed Apr 4, 2026

View reviewed changes

Comment thread apps/server/src/persistence/Layers/ProviderUsageLimits.ts Outdated

chatgpt-codex-connector Bot reviewed Apr 4, 2026

View reviewed changes

cursor Bot reviewed Apr 4, 2026

View reviewed changes

Comment thread apps/server/src/provider/codexAppServer.ts Outdated

juliusmarminge reviewed Apr 6, 2026

View reviewed changes

github-actions Bot added size:XXL 1,000+ changed lines (additions + deletions). and removed size:XL 500-999 changed lines (additions + deletions). labels Apr 7, 2026

cursor Bot reviewed Apr 7, 2026

View reviewed changes

Comment thread apps/server/src/provider/Layers/ClaudeProvider.ts

Comment thread apps/server/src/server.ts

Berkay2002 added a commit to Berkay2002/bcode that referenced this pull request Apr 16, 2026

feat: display provider usage limits in settings

39a610c

Cherry-picked from upstream pingdotgg#1732 Conflicts resolved manually.

Aditya190803 force-pushed the feat/provider-usage-limits branch from f9aabcd to 171df70 Compare April 17, 2026 06:07

github-actions Bot added size:XL 500-999 changed lines (additions + deletions). and removed size:XXL 1,000+ changed lines (additions + deletions). labels Apr 17, 2026

macroscopeapp Bot reviewed Apr 17, 2026

View reviewed changes

Comment thread apps/server/src/provider/Layers/ClaudeProvider.ts Outdated

cursor Bot reviewed Apr 17, 2026

View reviewed changes

Comment thread apps/server/src/provider/providerUsageLimits.ts Outdated

github-actions Bot added size:XXL 1,000+ changed lines (additions + deletions). and removed size:XL 500-999 changed lines (additions + deletions). labels Apr 17, 2026

cursor Bot reviewed Apr 17, 2026

View reviewed changes

Comment thread apps/server/src/provider/codexAppServer.ts Outdated

cursor Bot reviewed Apr 17, 2026

View reviewed changes

Comment thread apps/server/src/provider/Layers/ClaudeProvider.ts Outdated

Aditya190803 added 2 commits May 6, 2026 18:40

refactor(migrations): streamline auth_sessions migration by removing …

ec30593

…unused checks for pairing_links

feat(provider): enhance ClaudeProvider with usage limits parsing and …

d4d45ba

…improve server layer integration

cursor Bot reviewed May 6, 2026

View reviewed changes

Comment thread apps/server/src/provider/Layers/CursorProvider.ts Outdated

Comment thread apps/server/src/provider/Layers/ProviderUsageState.ts

Comment thread apps/server/src/persistence/Migrations/029_AuthCompatibilityColumns.ts Outdated

feat(provider): implement provider instance ID handling in usage stat…

2243d19

…e management

cursor Bot reviewed May 6, 2026

View reviewed changes

Comment thread apps/server/src/provider/claudeUsageProbe.ts Outdated

Aditya190803 and others added 2 commits May 6, 2026 21:09

feat(provider): enhance usage limits probing with clock abstraction a…

d1c0982

…nd argument parsing

Merge branch 'main' into feat/provider-usage-limits

c7a580a